Als nächstes wollen wir uns die Grundlagen der Interprozesskommunikation anschauen,

oder kurz IPC, dabei werden wir sowohl betrachten, wie verschiedene Prozesse innerhalb eines

Systems untereinander kommunizieren können, oder eben, wie Prozesse, die auf räumlich

getrennten Computern laufen, ebenfalls miteinander kommunizieren können.

Dazu schauen wir uns zunächst einmal das Client-Server-Modell an.

Hier wird unterschieden zwischen einem Client, der eine Anfrage stellt, und einem Server,

der diese Anfrage beantwortet.

Der Server ist aber ein Programm, das einen bestimmten Dienst anbietet, der über irgendeinen

Kommunikationsmechanismus angefragt werden kann.

Für gewöhnlich laufen Server-Anwendungen als Benutzerprozess.

Der Ablauf sieht nun aus wie folgt, dass ein Client eine Anfrage an einen Server schickt.

Anschließend wartet der Client auf die Antwort des Servers.

Der Server hingegen nimmt diese Anfrage an, bearbeitet diese und schickt das Ergebnis

der Anfrage wieder an den Client zurück.

Ab hier stellt sich die Frage, woher der Client eigentlich weiß, wie er den Server erreichen

kann.

Woher weiß der Client, welcher der vielen Prozesse auf dem System gerade der ist, an

den die Anfrage gestellt werden muss?

Wenn wir nun versuchen innerhalb eines einzelnen Systems einen anderen Prozess zu identifizieren,

dann können wir dies über die Prozess-ID machen.

Das Problem an der Stelle ist aber nun, dass Prozesse dynamisch erstellt und terminiert

werden können.

Und dies wirkt sich auf die Vergabe der PID aus.

Das bedeutet, nur weil ein Server bei der einen Ausführung die eine PID hat, können

wir nicht unterstellen, dass bei der nächsten Ausführung des Servers die PID konstant

bleibt.

Tatsächlich ist es sogar unwahrscheinlich, dass die PID bei der nächsten Ausführung

dieselbe ist.

Was wir stattdessen brauchen, ist die Einführung eines abstrakten Namens, unter dem der Dienst

erreichbar ist.

In diesem Beispiel bietet der Server Prozess 2 ein Unix-Socket über das Dateisystem an.

Das Socket ist unter dem Namen temp2 erreichbar.

Möchte sich nun ein Client-Prozess mit dem Server verbinden, dann braucht er nur den

Namen des angebotenen Sockets zu kennen, der unabhängig von der PID des Server-Prozesses

ist.

Das funktioniert soweit ganz gut, wenn sich die beteiligten Prozesse auf demselben System

befinden und damit Zugriff auf dasselbe Dateisystem haben.

Schwieriger wird es nun, wenn wir Prozesse haben, die auf verschiedenen Systemen laufen,

wobei diese zum Beispiel über ein Netzwerk miteinander verbunden sind.

Jetzt stellt sich die Frage, wie kann in diesem Fall ein Client einen Server finden?

Hier steht man nun vor dem Problem, dass man sowohl das System finden muss, auf dem ein

bestimmter Dienst läuft, als auch den Prozess innerhalb des Systems.

Ein Beispiel, wie dies gelöst wird, ist zum Beispiel TCP-IP.

Hier wird ein einzelnes System über eine IP-Adresse identifiziert und innerhalb eines

Systems kann ein bestimmter Prozess über eine Portnummer identifiziert werden.

Zur Adressierung im Internet haben wir also IP-Adressen.

Auf der einen Seite gibt es die alten IPv4-Adressen.

Das sind 4-byte-Werte, die eine Adresse ergeben.

Daraus ergibt sich ein 32-Bit-Adressraum, der ungefähr 4 Milliarden Adressen ergibt,

wobei einige dieser Adressen reserviert sind und nicht genutzt werden dürfen.